Problem model for alarm correlation

ABSTRACT

A method of processing data such as alarms from a communications network, the network comprising a plurality of network entities, having predetermined states of operation, the method comprising the step of creating an object ( 88 ) associated with a given state of one of the entities, such as a fault state. The object comprises knowledge based reasoning capability ( 89 ) such as rules for determining whether the entity is in the given state, and the method further comprises the steps of: passing data about the network, such as alarms and events, to the object; and inferring whether the entity is in the given fault state using the rules. This enables faster correlation of alarms and simpler development and maintenance of the rules.

FIELD OF THE INVENTION

The present invention relates to methods of processing data fromcommunications networks, systems for processing data from communicationsnetworks, methods of diagnosing causes of events in complex systems,methods of acquiring knowledge for knowledge based reasoning capacityfor the above methods, methods of extending compilers for such knowledgebased reasoning capacity, and methods and systems for using suchextended compilers.

BACKGROUND TO THE INVENTION

In complex systems such as communication networks, events which canaffect the performance of the network need to be monitored. Such eventsmay involve faults occurring in the hardware or software of the system,or excessive demand causing the quality of service to drop. For theexample of communication networks, management centres are provided tomonitor events in the network. As such networks increase in complexity,automated event handling systems have become necessary. Existingcommunication networks can produce 25,000 alarms a day, and at any timethere may be hundreds of thousands of alarms which have not beenresolved.

With complex communication systems, there are too many devices for themto be individually monitored by any central monitoring system.Accordingly, the monitoring system, or operator, normally only receivesa stream of relatively high level events. Furthermore, it is notpossible to provide diagnostic equipment at every level, to enable thecause of each event to be determined locally.

Accordingly, alarm correlator systems are known, as shown in FIG. 1 forreceiving a stream of events from a network, and deducing a cause ofeach event, so that the operator sees a stream of problems in the senseof originating causes of the events output by the network.

The alarm correlator shown in FIG. 1 uses network data in the form of avirtual network model to enable it to deduce the causes of the eventsoutput by the network. Before the operation of known alarm correlatorsystems is discussed, some details of how alarms are handled within thenetwork will be given, with reference to FIG. 2. Several layers of alarmfiltering or masking can occur in between a device raising an event, andnews of this event reaching a central system manager. At the hardwareelement (HE) level, the system would be overwhelmed, and performancedestroyed if every signal raised by hardware elements were to beforwarded unaltered to higher layers. Masking is used to reduce thisflood of data. Some of the signals are always suppressed, others delayedfor a time to see if a higher criticality signal arises, and suppressedif such a signal has already been sent.

Some control functions may be too time critical to be handled bystandard management processes. Accordingly, either at the hardwareelement level, or a higher level, some real time control may beprovided, to respond to alarms. Such real time control (RTC) has a sideeffect of performing alarm filtering. For example, a group of alarmsindicating card failure, may cause the real time controller to switchfrom a main card to a spare card, triggering further state changemodifications at the hardware element level. All this information may besignalled to higher levels in a single message from the RTC indicatingthat a failure and a handover has occurred. Such information can reachthe operator in a form indicating that the main card needs to bereplaced, an operation which normally involves maintenance staff input.

A node system manager may be provided as shown in FIG. 2, to give somealarm filtering and alarm correlation functions. Advanced correlationand restoration functions may be located here, or at the network systemmanagement level.

In one known alarm correlation system, shown in U.S. Pat. No. 5,309,448(Bouloutas et al), the problem of many alarms being generated from thesame basic problem is described. This is because many devices rely onother devices for their operation, and because alarm messages willusually describe the symptom of the fault rather than whether it existswithin a device or as a result of an interface with another device.

FIG. 3 shows how this known system addresses this problem. A faultlocation is assigned relative to a device, for each alarm. A set ofpossible fault locations for each alarm is identified, with reference toa stored network topology.

Then the different sets of possible fault locations are correlated witheach other to create a minimum number of possible incidents consistentwith the alarms. Each incident is individually managed, to keep itupdated, and the results are presented to an operator.

Each of the relative fault locations are internal, upstream, downstream,or external. The method does not go beyond illustrating the minimumnumber of faults which relate to the alarms, and therefore itseffectiveness falls away if multiple faults arise in the selected set,which is more likely to happen in more complex systems.

Another expert system is shown in U.S. Pat. No. 5,159,685 (Kung). Thiswill be described with reference to FIG. 4. Alarms from a networkmanager 41 are received and queued by an event manager 42. Afterfiltering by an alarm filter 43, alarms which are ready for processingare posted to a queue referred to as a bulletin board 44, and the alarmsare referred to as goals. A controller 45 determines which of the goalshas the highest priority. An inference engine 46 uses information froman expert knowledge base 47 to solve the goal and find the cause of thealarm by a process of instantiation. This involves instantiating a goaltree for each goal by following rules in the form of hypothesis treesstored in the expert knowledge base. Reference may also be made tonetwork structure knowledge in a network structure knowledge base 48.This contains information about the interconnection of a networkcomponents.

The inference process will be described with reference to FIG. 5. Firsta knowledge source is selected according to alarm type. The knowledgesource is the particular hypothesis tree. Hypothesis trees, otherwiseknown as goal trees are stored for each type of alarm.

At step 51 the goal tree for the alarm is instantiated, by replacingvariables with facts, and by executing procedures/rules in the goal treeas shown in step 52. If the problem diagnosis is confirmed, the operatoris informed. Otherwise other branches of the goal tree may be tried,further events awaited, and the operator kept informed as shown in steps53 to 56.

This inference process relies on specific knowledge having beenaccumulated in the expert knowledge base. The document describes aknowledge acquisition mode of operation. This can of course be anextremely labour intensive operation and there may be great difficultiesin keeping a large expert knowledge base up to date.

A further known system will be described with reference to FIG. 6. U.S.Pat. No. 5,261,044 (Dev et al) and two related patents by the sameinventor, U.S. Pat. No. 5,295,244, and U.S. Pat. No. 5,504,921, show anetwork management system which contains a model of the real network.This model, or virtual network includes models of devices, higher levelentities such as rooms, and relationships between such entities.

As shown in FIG. 6, a room model 61 may include attribute objects 62,and inference handler objects 63. Device models 64, 65, may also includeattribute objects 66, 67 and inference handler objects 68, 69. Objectsrepresenting, relationships between entities are also illustrated. Thedevice models are linked by a “is connected to” relationship object 70,and the device models are linked to the room model by “contains”relationship objects 71, 72.

The network management system regularly polls all its devices to obtaintheir device-determined state. The resulting data arrives at the deviceobject in the virtual model, which passes the event to an inferencehandler attached to it. An inference handler may change an attribute ofthe device object, which can raise an event which fires anotherinference handler in the same or an adjacent model.

The use of object orientated techniques enables new device models to beadded, and new relationships to be incorporated, and therefore eases theburden of developing and maintaining the system.

However, to develop alarm correlation rules for each device, it isnecessary to know both what other devices are linked to the firstdevice, and also how the other devices work. Accordingly, developing andmaintaining the virtual network model can become a complex task, asfurther new devices, new connections, or new alarm correlation rules areadded.

SUMMARY OF INVENTION

The invention addresses the above problems.

According to a first aspect of the invention there is provided a methodof operating a communications network comprising a plurality of networkentities, having predetermined states of operation the method comprisingthe step of creating an object associated with a given state of one ofthe entities, the object comprising knowledge based reasoning capabilityfor determining whether the entity is in the given state, and the methodfurther comprising the steps of:

passing data about the network to the object; and

inferring whether the entity is in the given state using the reasoningcapability.

By creating an object associated with a given state of one of theentities, a number of advantages arise. Firstly, the object orientedfeature of encapsulation limits the amount of communication to thatwhich is relevant, which can increase the speed of correlation.Furthermore, separation of problem modelling allows for improved reuseof code across different devices. A problem object can undertakerelatively complex tasks such as launching tests, verifying complexconditions, and controlling recovery behaviour which would be difficultto do by combining rules without the problem oriented structure.

Advantageously the given state is a fault state. The data about thenetwork may comprise alarms or other events relating to abnormal orundesired operation of the network. The example of alarm correlation isparticularly valuable in communication networks where alarms areunlikely to be sufficiently detailed to isolate the problem whichoriginally caused the alarm.

Advantageously a plurality of objects are created associated withdifferent states, and messages are passed between the objects as part ofthe inference process. Message based reasoning makes distribution ofprocessing easier, which facilitates scaling to handle a wide range ofnetwork sizes, topologies, and real time requirements.

Advantageously the object creation step is triggered by an eventnotified by the network, and the given state is a possible cause of theevent, or a possible consequence of the event.

Advantageously the reasoning capability comprises rules groupedaccording to the class of messages they can process. This structuring ofknowledge ensures fast alarm correlation. Groups of rules may be definedfor both problem classes and problem instances.

Advantageously the reasoning capability comprises rules for translatingevents notified by the network into a degradation of a service receivedor offered by the associated entity from or to other entities. Thisenables particular efficient reasoning, since service informationexpresses precisely how the operations of the entity are interdependent, which enables causes and consequences to be determined andpropagated quickly.

Advantageously such service degradation information is passed to otherobjects associated with the same or the other entities.

Advantageously two or more of said objects are created and the inferencesteps for each are carried out in parallel in threads sharing a commonknowledge base. This may be done using separate processors, and enablesthe processing to be distributed to suit performance requirements.

Advantageously knowledge bases are built up for separate parts of anetwork, and the method of claim 1 is carried out in parallel on theseparate parts. The inference step may be carried out using respectiveones of the knowledge bases and messages are passed from one object inone knowledge base to a connected object in an other, transparently.This is another way of distributing the processing, to scale thesolution as required.

Advantageously, a plurality of objects are created in one of theknowledge bases and the inference steps for each of the objects arecarried out in parallel, in threads, wherein messages passed from theseobjects contain a reference to the thread in which they were processed.This enables the messages to be returned to the correct thread.

According to another aspect of the invention, there is provided a systemarranged to operate a communications network as set out above.

According to another aspect of the invention, there is provided a methodof acquiring knowledge for the knowledge based reasoning capacity forthe method of claim 1, comprising the step of creating rules fortranslating events notified by the network relating to the associatedentity, into a degradation of a service offered by the associated entityto other entities.

According to another aspect of the invention, there is provided a methodof processing data from a communications network, comprising the stepsof:

implementing classes corresponding to given states of network entitieswherein each class comprises a static and dynamic part, the dynamic partconnecting instances of each class to rules which provide theirreasoning capacity, whereby the dynamic part held by the static part canbe changed while a system using these classes for its operation isrunning thus changing the behaviour of future instances.

This facilitates updating and maintaining the rules.

Advantageously the rule implementation referenced by the dynamic partcan be changed. This enables the behaviour of existing instances to bechanged. Advantageously the rules reference by the dynamic part arecompiled rules with their source code, rather than rule source whichrequires interpreting. This speeds up the operation considerably.

Advantageously the method further comprises the step of compiling therules using an extended compiler for an object oriented language,extended to compile rule constructs, wherein all the standard constructsof the language can be embedded in the rule constructs, and wherein therule constructs comprise sets of arrangements of conditions and sets ofsequences of actions that have an arbitrarily complex logical dependencyon the sets of conditions. The encoding of rules directly in the OOlanguage of implementation avoids the “impedance mismatch” problem.(Impedance mismatch is a classical problem arising from the clashbetween the data modelling styles of two paradigms, in this case 00 andKBS. This clash imposes a high cost of translation, both in performancewhen running the system, and in code maintenance when coding thetranslation between modelling styles.)

Advantageously the data comprises notification of an event in thenetwork and the rules are for determining the cause of the event.

According to another aspect of the invention there is provided a methodof processing data from a communications network, comprising the stepof:

applying a knowledge based reasoning capability to interpret the data,wherein the reasoning capability comprises a hierarchy of rulebases, thehierarchy being arranged to have inheritance properties, such that themethod further comprises the steps of;

determining whether a named rule is in one of the rulebases, and, whereit is not present, making available the same named rule from a rule basehigher in the hierarchy; and

applying the named rule to the data.

An inheritance hierarchy means that technology specific rule bases andproduct specific rule bases can be provided. This means supplierprovided rule bases can be updated without overwriting customer specificrules at a lower level of the hierarchy.

According to another aspect of the invention there is provided a methodof processing data from a communications network comprising the step of:

applying a knowledge based reasoning capability to interpret the datawherein the reasoning capability comprises one or more rulebases,comprising rules encoded directly in an object orientated language, byspecialising selected classes of an object oriented compiler soextending its functionality that it compiles rules and standard code.

This enables a class library and other object oriented applications tobe available not merely within the rules, but also when writing,compiling and testing them. Specialising a limited number or a minimumnumber of selected classes means that large parts of the compiler remainidentical in their implementation. Thus many ancilliary tools willcontinue to interwork with the new compiler.

Advantageously the compiler is a Smalltalk compiler. Advantageously themethod comprises the step of applying the reasoning to determine thecause of events notified by the network.

According to another aspect of the invention there is provided a methodof extending a compiler for an object oriented language, to compile ruleconstructs, wherein all the standard constructs of the language can beembedded in the rule constructs, and wherein the rule constructscomprise sets of arrangements of conditions and sets of sequences ofactions that have an arbitrarily complex logical dependency on the setsof conditions.

Advantageously, the rule constructs may have any other data andbehaviour defined in the language. This enables names and references tothe context of the rule, or variables, to be included in the rules. Thiscan further simplify the rules, and ease maintenance.

According to another aspect of the invention there is provided a systemcomprising a processor arranged to use a compiler extended according tothe above method of extending a compiler.

Preferred features may be combined and may be combined with any of theaspects of the invention, as appropriate, as would be apparent to askilled person.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the invention, and to show how the samemay be carried into effect, it will now be described by way of examplewith reference to the drawings, in which:

FIGS. 1, 2, 3, 4, 5 and 6 show prior art systems and methods for alarmcorrelation;

FIG. 7 shows the structure of the environment of an alarm correlationapplication of an embodiment of the present invention;

FIG. 8 shows the structure of the alarm correlation application of FIG.7;

FIG. 9a shows a problem class inheritance hierarchy for use in theapplication of FIG. 7;

FIG. 9b shows a method using a dynamically represented problem class;

FIG. 10 shows a rulebase inheritance hierarchy for use with theapplication of FIG. 7;

FIG. 11 shows a method of problem diagnosis used by the application ofFIG. 7;

FIGS. 12a, 12 b, 12 c and 12 d show the structure and function ofelements of the application of FIG. 7 for semi local reasoning;

FIGS. 13a, 13 b, 13 c and 13 d show the structure and function ofelements of the application of FIG. 7 for local reasoning;

FIG. 14 shows the structure of a managed unit arranged for localreasoning;

FIG. 15 shows managed unit and interactor object operation under localreasoning;

FIG. 16 shows communities of managed units suitable for semi localreasoning;

FIG. 17 shows the generic network model used to model a network in termsof managed units and their interactions-,

FIG. 18 shows this model extended by the fault behaviour of the managedunits to support semi-local reasoning about the location of faults;

FIGS. 19, 20, 21 and 22 show state models of objects with non-trivialbehaviour in this model;

FIG. 23 shows this model further extended to support purely localreasoning about the location of faults;

FIGS. 24, 25, 26, 27, 28, 29 and 30 show state models of objects withnon-trivial behaviour in this model;

FIG. 31 shows how default and active (problem) behaviour states may beimplemented; and

FIGS. 32 and 33 show features of the architecture concerningdistribution.

DETAILED DESCRIPTION

Environment

FIG. 7 shows a network system manager 81 linked to the network itmanages. The manager has a user interface 82, and feeds otherapplications through a network data access function 83. The alarmcorrelation application 84 is illustrated with its own user interfacefunction 86. The alarm correlation application is an example of anapplication which can infer whether an entity in the network is in agiven state of operation. It is also an example of an application whichcan determine the cause of an event, or consequences of an event in thenetwork, using a virtual model of the network.

Alarms and notifications of other events, such as network trafficchanges, and cell loss rates are passed to the alarm correlationapplication from the manager. The correlation application converts thestream of events into a stream of causes of the events, also termedproblems. These problems are made available to a user via the userinterface. This enables a user to take prompt remedial action based oncauses rather than symptoms.

Introduction to Correlation Application Structure, FIG. 8

The general structure of the correlation application is shown in FIG. 8,and its function will be described in general terms before each of theelements are described in more detail.

The application can be divided into three sub domains, a generic networkmodel 87, a fault model 88, and knowledge management 89. Broadlyspeaking, events are notified to parts of the model corresponding to thelocation of the event. The network model passes them to the fault modelto update the model of possible causes of the fault. This is done byreference to rules in the knowledge management part. In turn, theserules may refer to the network model, and may cause it to be updated.Thus causes and consequences of the events propagate through the models.If the fault model determines from subsequent events and knowledge ofnetwork behaviour that a possible cause must be the true cause, the useris alerted.

Introduction to the Generic Network Model 87

The level of knowledge of network behaviour represented in this model ofthe network depends on how much is contained in other sub domains. Twoexamples of different levels will be discussed. In one of theseexamples, the model contains information about services received oroffered between network entities. This is described in UK patentapplication 941227.1 in the context of capability management.

Introduction to Fault Model Subdomain 88

The fault model 88 contains knowledge on abnormal or unwanted networkbehaviour. As will be discussed below, such knowledge is organised instructures of problem classes, representing failure modes which causealarms or other events. Instances of problem classes are created forpossible causes of events as they are notified. The problem instancesare allocated rules according to their problem class, to enable them toresolve for themselves whether the cause they represent is the truecause.

Introduction to Knowledge Management Subdomain

These rules are held in a structured way in the third sub domain, calledknowledge management 89.

The level of complexity of the rules depends on the level of knowledgeof network behaviour stored in the model 87.

The structure described combines elements of object oriented methods andknowledge based methods to achieve particular advantages. The separationof problem and rule base knowledge facilities rule reuse and access torules.

Introduction to Inheritance Hierarchy within Sub Domains

Within the fault model, problem classes can be arranged in aninheritance hierarchy, as shown in FIG. 9A. In practice there will bemore classes than those illustrated. This means when a problem objectinstance is created, it can inherit generic characteristics such asreferences to rules, from higher levels of the hierarchy, as well asmore specific characteristics. This facilitates development andmaintenance of the fault model, since new failure mode problem classescan adopt generic characteristics, and such generic characteristics canbe altered.

Within the knowledge management, a similar hierarchy structure can existas shown in FIG. 10, with similar advantages. Rulebases 190, 191, and192 are linked such that when a named rule is not present in one of therulebases, it is made available from a rule base higher in thehierarchy.

Introduction to Dynamic representation of Problem Classes

When creating problem objects, there are advantages in representingproblem classes in a dynamic form. As shown in FIG. 9b, if the problemclasses are implemented in classes which have a static and dynamic part,the dynamic part connecting instances of the class to rules, the dynamicpart held by the static part can be changed while a system using theseclasses for its operation is running. Thus existing problem objects willbehave according to their old rules, while new problem objects can havenew behaviour, and there is no need to stop the system when changing arulebase.

Step 200 in FIG. 9b shows an event being received by a corresponding MU.Next, at step 201, if appropriate, a new problem object is created usingone of the problem classes, according to the type of event. The probleminstance has access to its class' static part, eg name and meaning offailure mode, and dynamic part, as shown in steps 202 and 203. Pointerscan be used as run time data to connect to rules.

Overview of Problem Diagnosis Function

FIG. 11 shows a method of problem diagnosis used by the application ofFIG. 7, expressed in general terms applicable to both the localreasoning and semi local reasoning examples which will be describedbelow. An event is notified by the network system manager at step 140,and sent to affected problems at step 141. At step 142, the problems maychange their own state and/or the state of the network model. Then atstep 143 messages about changes are sent to affected neighbours or to acommunity of connected devices in the model. Again, these affectedneighbours will send messages to their associated problems at step 141,the cycle is continued, until the effects of the event have propagatedas far as possible. If any particular problem's state changes to true,from possible, then a diagnosis for that event is completed and the useris advised, at step 144. Rival possible problems are quiesced by thesame message passing cycle above described.

Introduction to Local and Semi Local Reasoning

To limit the number of different types of messages each object wouldneed to be able to handle, for a practical system, the messaging can bedesigned to be limited to messages between problems related to the sameentity or between problems and their behaviour interactors. This iscalled local reasoning. If extended to cover entities in a limitedcommunity, this will be referred to as semi local reasoning. For thelocal reasoning case, this has the consequence that the rules can besimplified, though the network model needs to have a deeper level ofknowledge of network behaviour. For the semi local reasoning case, therules need to cover a wider range of possibilities, but the networkmodel can be simpler. Broadly speaking semi local reasoning is easier toimplement but slower to operate.

The structures and functions of the two strategies will now be explainedin general terms with reference to FIGS. 12a-d and 13 a-d.

Introduction to Semi Local Reasoning

FIG. 12a shows the structure of a small part of the generic networkmodel 87. Managed units 91 corresponding to entities in the network,either physical entities such as line cards, or virtual entities such asvirtual channels, are connected by passive interactors. These areobjects which are shared by a pair of connected managed units. Thepassive interactor objects limit the communication between managedunits, and may pass only messages relating to the state of servicesbetween managed units. Only three such managed units 91 are shown, forthe sake of clarity.

For semi local reasoning, these interactors may be passive, whereas forlocal reasoning, they incorporate some of the knowledge of networkbehaviour, and are called behaviour interactors.

FIG. 12b shows a part of the fault model for the semi local reasoningversion. The fault model contains problem classes for failure modes ofeach of the managed units shown in FIG. 12a. Instances of possibleproblems which could be the cause of notified events will be created inthe fault model 88.

FIG. 12c shows the knowledge management for the semi local reasoningversion. Rules for each of the managed units are shown. The problemclasses shown in FIG. 12b will have references to these rules. For eachmanaged unit, there must be rules representing how the behaviour of eachmanaged unit is degraded by an internal problem with that managed unit.Furthermore, for the semi local reasoning version only, it is necessaryto have rules representing how the behaviour of each managed unitdepends on problems with other managed units in the community.

FIG. 12d shows the operation of the semi local reasoning version. Anevent arrives at its corresponding managed unit at step 121. It ispassed to associated problems at step 122. Each problem object consultsits rules to determine which to fire at step 123. Firing rules maychange the state of the problem as shown as step 124. Alternatively, oras well, the event may be broadcast to a community of service linkedmanaged units at step 126. At step 125 any change of state of theproblem is also broadcast to the community of managed units. In turn,these managed units receiving the broadcast messages will pass events totheir associated problems at step 122 and the cycle continues. In thisway, causes and consequences of events are propagated through thenetwork model. If at any time a problem state has enough information tobecome true, rather than merely being a possible cause of the event, theuser is advised at step 127.

Introduction to the Local Reasoning Version

For the local reasoning version, the managed units 92 share behaviourinteractors which control interactions between managed units 92.According to the local reasoning strategy, problems do not broadcastmessages, or receive messages concerning any units other thanneighbouring units connected via the behaviour interactors. Accordingly,the rules for each problem can be simpler, but the behaviour of theinteractors need to have some knowledge of the impact of neighbouringmanaged units on each other in terms of services offered and received.

FIG. 13b shows the fault model 88 with problems for each of the managedunits of the network model 87. FIG. 13c shows the knowledge management89 for the local reasoning version. In relation to each managed unit,the rules need to represent how the managed unit is degraded by aninternal problem or degraded interactor states. There is no need for therules to represent directly how the behaviour is degraded by problemswith other managed units.

FIG. 13d shows the operation of the local reasoning version. An eventarrives at a corresponding managed unit at step 150. It is passed to itsproblems at step 151. Each problem consults its rule list to determinewhich rules to fire. Firing rules changes the state of problems at step153. The problem in its new state asserts its MU and interactors servicedegradation causes and consequences at step 154. At step 155 affectedinteractors pass messages about degradation of services onward to MUsproviding or receiving such services. Problems associated with suchother MUs then consult their rule lists to determine which to fire, atstep 152, and the cycle continues. Problems are continually trying toascertain if they are the true cause of a particular event. If a problemstate becomes true as a result of the propagation of causes andconsequences, the user is advised of the diagnosis at step 156.

FIG. 14 shows the structure of a managed unit 193 supporting localreasoning. Services offered 194 to another managed unit 198 arerepresented in the form of an interactor object 196 shared between thetwo managed units. Likewise for services received 195. The behaviour 197of the managed unit has lists of rules 199 which react to messagesreceived and relate services offered to services received. Messages mayalso be output according to the rules.

FIG. 15 illustrates the operation of the managed unit and interactorunder local reasoning. At step 220 the interactor receives messagesindicating state changes. The interactor passes the message to the farend and updates its state as appropriate at step 221. The managed unitreceives a message indicating its services have changed at step 222,from the interactor. The behaviours of the managed unit process themessage using rules to determine the the effect on other servicesoffered or received at step 223. The managed unit passes the message tothe same or other interactors about altered service states at step 224.At step 225, interactors send messages to their far ends, indicatingservices are changed at step 225, to propagate the causes andconsequences to neighbouring managed units.

FIG. 16 shows how the managed units may be members of correlationcommunities 234, 235. These communities are made up of service linkedmanaged units whose corresponding entities are functionallyinterdependent, such that bursts of alarms may relate to a single causewithin the community. A single managed unit may be a member of more thanone community. The communities serve to limit the reasoning to semilocal reasoning.

The application domain will now be described in more detail, as thereasoning framework is located there.

1.1 Aims

The two principal aims of the alarm correlator are to provide:

a) a set of algorithms (using this word in a broad sense) to mapdisorderly partial sequences of events into fault diagnoses;

b) these algorithms requiring knowledge that is easy to gather andmaintain.

Both the algorithms and the activity of knowledge acquisition mustfunction within their (very different) performance constraints;real-time correlation in the first case, finite cost reverse engineeringor minimal cost capture during development of the telecomms devices, inthe second.

1.1.1 The Application Mission

A correlator inferences over a model of the objects in the network andtheir interconnections. The semantic richness of this model is part ofthe application and may exceed that of the network model held in theManangement Information Base of the manager of the network whose alarmsare being correlated. However, the data for this model comes exclusivelyfrom the network manager. How this is done is would be apparent to askilled person and will not be discussed in detail.

A correlator also inferences over a model of (hypotheses about) thefaults in the network and their interrelationships; this model thereasoning framework area constructs. Correlation is precisely theactivity of producing from the available data the most accurate possiblemodel of the faults in the network.

Faults are modelled as problems. Each problem is an offer to explaincertain observed events. Hence, a problem may be a rival to, aconsequence of or independent of another that offers to explain some ofthe same events. Problems communicate with each other via messages.Problems process the messages they receive using rules.

Two main strategies are envisioned for inter-problem communication.

1) Semi Local Reasoning

A broadcast strategy: problems broadcast messages that they cannot dealwith alone to the correlation community(ies) to which their Managed Unit(MU) belongs. All problems of all MUs in the community receive themessage.

2) Local Reasoning

An impact strategy: each problem computes the meaning of each message itreceives in terms of impacts on the states of services of its MU. Asthese services connect the MU to its neighbours, impacts on themtranslate directly into messages to those neighbours' problems.

(In either case, a problem that acquires a given relation, e.g.consequence or rival, to another problem via a message may thereaftercommunicate with it directly when appropriate.)

The application domain models the functional design for achieving thesestrategies, independent of all performance considerations. As shown inFIG. 8, the application can conveniently be divided into threesubdomains. The three subdomains, the Generic Network 87, the FaultModel 88, and Knowledge Management 89, have many and complexinterrelationships. Each will now be described.

1.1.1.1 Generic Internal Model Subdomain

Network correlation requires a model of the network over which toinference. The Generic Internal Model is defined as a high levelframework of classes and relations that are used to represent networkdata. The two strategies for interproblem communication requiredifferent levels of structure in the model.

The broadcast strategy requires a fairly basic model of which MUs areconnected to others; the detail of what the connections signify isencoded in the broadcast rules which may traverse many connections whileevaluating their conditions.

The impact strategy requires more substructure and better-definedinterfaces between MUs as it only envisages rules whose conditionstraverse a single link.

In the broadcast strategy, units of management (MUs) are connected bypassive relationship objects called interactors. MUs are collected intocommunities which represent a group of connected MUs performing a commonfunction. One MU may belong to several communities.

In the impact strategy, MUs are internally structured as sets ofbehaviours, some of which they can export as capabilities while othersenhance capabilities they have imported from other MUs. Behaviours areconnected by behaviour interactors (peer-peer by bindings andsubordinate-superior by provisions). These induce the MU interactorconnections of the broadcast model. The communities of that model arethe roots of capability chains in this (N.B. a typical broadcast modelwould not implement all roots as communities but only such as seemeduseful).

A general model, allowing for making and breaking of provisions andbindings, would enable the model to be updated automatically using alink to Configuration Management functions (CM). The interface betweenCM and Fault Management (FM) is a specialisation of this model thatdescribe only a correctly connected network of functioning behaviours.This specialised model contains precisely those elements common to CMand FM. It has no CM-specific behaviour (it assumes acorrectly-provisioned network) and no FM-specific behaviour (it assumesthe absence of faults).

1.1.1.2 Fault Model Subdomain

Both approaches model faults as problems, representing aberrantbehaviour of an MU (as noted, the impact strategy also models the normalbehaviour—hereafter, just behaviour—of the MU). On a given MU, all suchproblems have the default (quiescent) state of ‘not present’ and avariety of active states. (Similarly, the MU's behaviours have defaultstate of ‘normal operation’ and a variety of ‘behaviour degraded’states, as far as FM is concerned.)

The basic hypothesis of a problem object is that the MU has thatproblem. In the impact strategy, the basic hypothesis of a behaviour is,on the contrary, that any malfunction in it is due to malfunction inother behaviours supplied to it by other MUs. The problems capture theFM information of how a fault on an MU can degrade that MU's behaviours.The behaviours capture the CM information of how one MU depends onothers to perform its function. In the broadcast strategy, by contrast,this information is also held by the problems which must understandtheir remote as well as local consequences.

MUs receive alarms and other events from the devices they manage (overthe bridge from the SM-application domain). They send these to theirhypotheses which may react by changing state and/or emitting furthermessages. The behaviour of hypotheses when receiving messages isgoverned by rules.

1.1.2 Knowledge Acquisition

The rules that govern hypothesis behaviour must be designed and writtenfor each network following a knowledge acquisition process, andmaintained and configured to suit the needs of customers. The method bywhich this is done would be apparent to a skilled person and is notdescribed in detail. However, the advantages claimed by this inventioninclude making knowledge acquisition and maintenance easier and how itdoes so will be described below.

1.2 Relationships betwen the Invention's Functions and ExternalFunctions

The application places the following requirements on other domains.

1.2.1 System Manager

This must provide the data required by correlation algorithms from itsMIB. This data must be provided to the required performance.

The application can accept network data (configuration and state)synchronously or asynchronously, the latter being handled by themechanism of expectation events or by splitting a rule into two halves,one raising the request the other firing on the returning event.

The quality of correlation is a function of the quality of informationavailable from the system manager.

1.2.2 User Interface (UI) Domain

The user of the application has a number of tasks to perform at theclass level that require UI support.

Impact strategy alarm correlation class relations: the user will wish toassign Problems to MUs, assign Messages to Problems via Rule Name(s) andto write rule implementation for Rule Names for a chosen RuleBase.Whenever performing one of these tasks, the user will wish to know thecurrent context of the other two. They may move rapidly between them.

Broadcast strategy alarm correlation class relations: as above plus theuser will wish to define which messages get broadcast to whichcommunities by which MUs.

Broadcast strategy internal model class relations: the user will wish toassign MUs to communities. (It is assumed that each communitycorresponds to an MU that is a higher or lower root of a capabilitychain for compatibility with the impact strategy. In a model supportingthe broadcast strategy, the chain may not be defined but the existenceof the root MU may be assumed.)

Impact strategy internal model class relations: as for problem, the userwill wish to assign behaviours to MUs (s), assign Messages to Behavioursvia Rule Name(s) and write rule implementations for Rule Names for achosen RuleBase. Hence, the same UI is implied.

The user will also wish to assign MU interactors to MUs and assignbehaviour interactors to behaviours

The impact strategy's ability to put event-problem relationships intodata allows a UI in which the knowledge engineer would program such datastructures directly rather than coding them in rules.

The user of the application framework also has tasks to perform at theinstance level that require UI support, namely control and configurationof the run-time alarm correlator, display of problem and alarm data,display of rule debugging data

The injection of real or simulated events into the SM to test the ACwill require a suitable interface to the SM.

1.2.3 Infrastructure

A change control mechanism will be needed, including mechanisms forchecking the compatibility of given versions of MUs, Problems andRuleBases with each other when constructing an image.

1.3 Implementation Aspects

Hypotheses' rules are stored in RuleBases and supplied to them via aperformance-efficient indirection mechanism which will handle the casewhere default and active states of a hypothesis have the samerelationship to a given message class.

A hypothesis in its default state on an MU in the application domaincorresponds to that MU having no hypothesis instantiated in thearchitecture domain. Instead, the MU (class) has a link to thehypothesis class.

Related to the above, behaviour interactors reference their induced MUinteractor and the connected behaviours' classes whenever saidbehaviours are in their default states.

In using distribution to implement the correlation algorithms to therequired performance, appropriate granularity of reasoning processingper unit of event receipt processing must be provided. This means:

order-independent processing of SM events: the engine is not required toprocess events from the system management platform in the order in whichthey arrive or in any order as the rules must function on eventsarriving in any order.

(Note: this does not prohibit, indeed it allows, ordering the processingof incoming events according to some policy to maximise performance. Itis an anti-requirement, a permission.)

state-consistent processing of rules: while a rule is causing a statetransition of an MU, Interactor, Problem or Message, the object involvedmust not be read or written to by another rule: equivalently, rulesshould only fire on objects in states, not on objects transiting betweenstates. If two rules may want to perform operations on overlapping setsof objects, the protocol must include a mechanism to avoid deadlock.

Order-dependent processing within message trees: let a partial order onmessages be defined by each network event arriving from the SM being adistinct root and a message being lower than the message that fired therule that created it. Then the requirement is that the order in which agiven problem processes rules fired by two messages must not violatethis partial order.

Less mathematically, if a problem receives two messages, and if one ofthese messages was created by a rule fired by the other, then thatproblem must fire all rules that will be fired by the creating messagebefore it fires any that will be fired by the created message.

(Note that breadth first processing (one of the ways of meeting thisrequirement) is much stronger than this minimally requires but ensuresno deadlocks. Arranging that no ruleset of the created message will befired before all rulesets of the creating message is slightly strongerthan this minimally requires. The requirement relates only to the orderin which rules are fired on a given problem; there is no requirement forthe firing of rules on two different problems to respect the partialordering of the two messages that fired them.)

The advantage of this requirement is that if the customer writes rules,it can be assumed they understand the disordered input of externalevents. They cannot reasonably be expected to understand any disordering(e.g. caused by distribution) of the internal AC events that resolvethese external events. An AC developer is not so absolutely unable tohandle disordered internal events but as the rule base grows, they wouldfind the burden of allowing for them onerous.

2. The Generic Network Data Model

The correlator's task is to build a model of the faults in the network.It builds this on a model of the network. When the fault model assertsthe degradation of the service state of an object in the n/w data model,the latter provides the information for how this degradation impacts thestates of other related objects.

2.1 Introduction

This section discusses what is modelled and how it is modelled.

2.1.1 Design Aims and Constraints

Constraints on, and trade-offs for the design of the internal model are:

the information necessary in order to perform correlation:

need the concept of a correlation community for the broadcast strategy

need the concept of a service for the impact reasoning strategy

the desire to build a system suitable for service impact analysis (SIA)too: need the concept of a service to be included partly to support this

the difficulty of writing the rules (related to previous point)

the need to maintain correspondence with a range of external models

A restriction on encoding information in the model is that it must beavailable from the SM's MIB (or equivalent), at least as regardsinstance level information. Each network is different and it must bepossible to derive class level information needed by the internal modelfrom the network information automatically in some cases. Usually, classlevel information will have to be added during the creation of aparticular AC application.

2.1.2 Data and Knowledge to be Modelled

The generic network model data over which the fault model reasons is

a chosen set of real or virtual network objects

state data about the internals of these objects

configuration data about how these network objects are related to eachother

Changes to the latter two types of data may be advised by the same eventmechanism as supplies the first—discovery events, etc.—or by some othermeans. This data may influence the fault model which may also predictits values or occurrence.

In addition to the above instance data (data), there is class data(knowledge). This includes configuration knowledge about

(extra-object) service provision: what services network object classescan produce and consume, hence how these classes can be connected

(intra-object) service production: the relations between servicesconsumed by a network object and those it supplies to others; also therelations between these and the object's internal behaviour

There would also be configuration/FM knowledge about what events (inparticular, what alarms) an object can raise and in what states. (Thisrelates to AC knowledge about what problems a network object can haveand how these impact its states and the events it raises, which liesoutside the internal model).

2.1.3 Data Acquisition for the Internal Model

State and configuration data to populate the internal model is obtainedfrom the SM MIB. Should the application seek further data from thenetwork, it expects it to be returned synchronously, or in an eventwhich it can use to fire a rule on the requesting problem.

2.1.4 Knowledge Acquisition for the Internal Model

Ideally, configuration knowledge will be gathered and made available ina machine readable form, preferably as part of the SM functionality. Itshould be encoded in

the correlation community classes

the MU and Capability classes

the internal behaviour of MUs (services consumed=>services produced;capability rules)

There are two places that the knowledge needed to correlate alarms canbe stored: in the rules and in the model. The more that can be encodedin the model, the less needs to be put in the rules (and the moregeneric and less numerous they can be). Hence, we expect some ACknowledge to be gathered as detailed configuration knowledge,specifically as intra-object service production rules (services consumedunavailable to degree Y=>services produced unavailable to degree X;extended capability rules).

2.1.5 Order of Model Development

The various dimensions of the class side of a specific internal modelfor a given application area may be developed as follows:

a) The pure configuration model (also known as the stateless CM model):this model has MU classes with named (typed) capabilities that theyexport and import. It also has named (typed) peer-peer bindings and(exporter-importer) provisions. It has no capacity to show any objectfunctioning abnormally.

This model may be the output of a CM process or the necessary firststage of developing the full model. It is adequate to support thebroadcast strategy since roots of capability chains can be used toidentify correlation communities and the binding and provision linkssupport tracing of MU relationships within communities.

Note that for CM purposes, the above model would allow disconnection andreconnection of MUs. For FM, the subset that deals with correctlyprovisioned networks will be used (no free-floating MUs).

b) The CM model with interactor state (as regards FM, that is): thestateless CM model assumed that everything always worked; that is, ithad no means of indicating that anything was not in an ideal state.Interactor (FM) state can be added to it by assigning failure states toeach type of binding and provision.

This model simplifies rule writing by providing a set of failure statesthat MUs can use to signal impacts to each other. Thus it can supportthe impact strategy.

c) The interactor-state CM model with behaviour state and capabilityrules: to the above model, we add behaviour (FM) state to it byassigning failure states to each type of behaviour. We then addcapability rules mapping failure states on an MU's inputs to failurestates of its behaviours, and failure states of its behaviours tofailure states on its outputs.

This model is now fully developed as regards configuration. (Thecapability rules may be rules in the implementation sense, or a table ofstate relations held by the MU and driven by generic implementationrules, or a mixture of the two with generic data driven behaviour beingoverridden in some specific cases.)

2.2 Notes on Term Definitions

This section provides additional detail on the definition of some termsused above, to assist understanding.

2.2.1 Management Units

There are various definitions of what constitutes a valid MU class. Oneis that an MU is a replaceable unit (so that, for example, one wouldallocate termination point MOs to the MUs of selected adjoining MOs onthe grounds that one cannot tell the user to go and replace atermination point). This is our policy for physical objects.

At the logical level, there are no RUs and so we model alarm-raising Mosas MUs. However, MOs that are true components of others may be groupedat the logical level too. Another form of grouping likely at the logicallevel is collection MUs (also known as extents): single MUs that, tosave object overhead, represent not one but a collection of MOs.

2.2.2 Communities

A community is defined as a group of MUs, so connected that, for areasonable proportion of problems on community members, a burst ofalarms caused by a problem on one member of a community is whollyreceived by MUs within the community. We must provide communities tosupport broadcast reasoning.

Communities are identified with capability chain roots so that they areintegrated with the capability hierarchy aspect of the model. This islogical since for a group of MUs to be affected by a problem, they mustbe concerned in the function affected by the problem. Nevertheless, itshould be noted that communities do not need capabilities to bemodelled. (Indeed, their modelling can help later capability modelling.)The broadcast reasoning strategy uses communities based on upper andlower roots of capability chains.

2.2.3 Integrating Peer-Peer and Hierarchic Capability Connections

Regarding links between MUs, the model supports:

peer-peer links between MUs and

hierarchic links to collect together MUs to form higher level MUs

It integrates these two forms of relationship by a constraint asdescribed in the next section.

2.3 Capability Modelling Revisited

To explain how to implement integrated peer-peer and hierarchiccapability modelling, it will be described as a simplification of aricher modelling technique.

2.3.1 Rich Abstract Capability Modelling

Network models are constructed from MUs. Each MU has

a) behaviour: an extended finite state machine (EFSM) with transitionguards models the MU's behaviour

b) ports: a port has an alphabet of messages and message sequences thatit can input and output. Ports may be bound to each other, thusestablishing connections between MUs.

behaviour ports: these are ports that interact with the MU's behaviour;messages arriving at them may trigger transitions in the EFSM. They areclassified as

external ports: these may be bound to the external ports of peer MUs orto the internal ports of containing MUs

internal ports: these may be bound to the external ports of containedMUs

relay ports: these make external ports of contained MUs available asexternal ports of the containing MU directly, i.e. without interactingwith the containing MU's behaviour

Bindings between ports are relay bindings, connecting two ports of thesame type (one of which will be a relay port), and transport bindings,connecting two ports of conjugate types.

c) containment relationships: an MU may be contained within another MU.Each of its external ports may be bound

to one of the container's internal ports via a transport binding

to an external port of another MU contained in the same containing MUvia a transport binding

to an external port of the containing MU via a relay binding

Each unit of port functionality can be bound within only one other MUalthough the MU as a whole may be contained within many.

In this approach, an MU exports capability by providing one or moreports (usually two) to its containing MU plus the behaviour (its own orencapsulated from MUs within it) associated with those ports. An MUimports capability by binding the ports of the imported capability toits own external relay ports, to its own internal behaviour ports or toother imported ports (internal to it, external to the other MU whosecapability it also imported).

2.3.2 Simplified Capability Modelling

The above can describe any telecomms system we might want to model butis too rich for the requirements of this invention. Algorithmicallymatching behaviours and ports, as defined above, to establish validcapability provisions would be a hard problem and there is no need todefine MU classes in such detail. Hence the model will be simplified asfollows.

In place of ports with valid input messages and sentences, ports withone of a few named types are used.

In place of the EFSMs, or composite machines built from imported onesand enhancements, that were connected to these ports, named capabilitiesare used.

In this approach, a capability offer is a collection of external portsof specified type, all belonging to the same MU, plus a namedcapability, also with type information attached, spanning these ports.The capability name summarises the behaviour attached to the ports thattransforms their inputs into their outputs; i.e. it describes the typeof behaviour offered. The capability type identifies the granularitywith which that behaviour can be offered.

A capability requirement is likewise a set of ports (of conjugate typesto those of the offer ports) and a capability name describing thebehaviour required between these ports.

2.3.3 Simplifications for the Alarm Correlator

The AC can assume that it is dealing with correctly provisioned chains:no ‘free-floating’ MUs are possible. Hence certain simplifications arepossible (c.f. FIG. 17).

A binding of two conjugate ports can be modelled by a single objectrelating two behaviours (and thence between two MUs): hence the portobject becomes the port relationships between the binding and behaviourobjects. (Note: at the detailed implementation level it may neverthelessbe implemented as a collection of three closely related objects forefficiency reasons.)

A relay binding can become a relation between a port and the containingMU. Hence the relay port object becomes the manyness of the externalport's relationships.

2.4 The Generic Internal Network Model

At this stage in the modelling, there is a static (as it is correctlyprovisioned and nothing ever goes wrong) model of MUs containingbehaviours connected by bindings and capability provisions. This isillustrated with a hierarchy in FIG. 11.

As noted, port objects do not appear in this model; what were ports asdescribed above are now the relations between bindings and their boundbehaviours in the definitions below. However, for ease of description,reference will be made to a behaviour's ports, meaning its possiblerelations to bindings, below.

(Where objects in the internal model are specialised in the fault model,their more specialised name is given in brackets.)

2.4.1 Class Definitions

MU

MUs are units of granularity of management. In the CM world, they arewholly defined (at the application level) by their behaviours and ports.

MU Interactor

The various cross-MU (i.e. non-support) connections between behavioursinduce connections between the MUs owning those behaviours. In theimplementation, the MU Interactor is an important class containingreferences to the connections between behaviours, needed for efficiencyreasons. At the application level, it knows nothing its contents do notknow and has no interesting behaviour.

(Normal) Behaviour

A behaviour is an abstraction of a particular Extended Finite Statemachine. It is a name given to that machine. Every behaviour is owned bya particular MU, the one whose overall EFSM is composed of thatbehaviour's, possibly with others.

Capability

A capability is an exportable behaviour. Its exportability comes fromthe nature of its bindings which allow the behaviour to be put incommunication with the behaviour of the MU to which it is exportedand/or to other MUs bound to that MU.

Enhancement

An enhancement is a non-exportable behaviour internal to an MU which itconnects to one or more imported behaviours so as to enhance them into acomposite behaviour which it can export. Enhancements are always boundto imported behaviours on at least one of their ports, though they maybe externally bound on others.

Behaviour Interactor

This is a straightforward generalisation of Binding and Contain.

Binding

A binding is a peer-to-peer connection between two behaviours. When thebehaviours are considered as EFSMs, the binding allows them to exchangemessages. When they are regarded more abstractly, the binding justrecords that they are in communication and its name abstracts the typeof messages and message sequences they could exchange, just as thebehaviour's names abstract their EFSMs. Bindings are usuallybidirectional objects as they are passing information in two equaldirections (designated portA and portZ in the figure), althoughunidirectional bindings, or ones with a preferred direction to whichinformation in the reverse direction is subordinate, are possible.

In principle, binding is a standard many-many binary relationship, eachbinding connecting precisely one behaviour to precisely one other.However, when a behaviour has been imported into another in such a waythat the second incorporates part of the external interface of the firstin its own external interface, then, and only then, a binding may havemultiple behaviours at either or both of its ends. Any such set ofmultiple behaviours is necessarily an ordered sequence of capabilityimports.

Contain

This shows dependency of one behaviour on another. The containingbehaviour incorporates the contained into itself either by offering thecontained's external ports as its own, or by binding them to itsenhancement behaviours via its internal ports or by a combination ofboth.

Generic containment is a standard many-many binary relationship. Onebehaviour may support many others and be supported by many others.Specialisations may limit the degree of support a behaviour may offer toa single containment, to a finite number, etc.

Support

A specialisation of the contain relationship to cases where enhancementbehaviours of an MU are contained in exported behaviours of that sameMU, i.e. to cases where the containment relationship is between twobehaviours of the same MU. Supports, being intra-MU objects, are notrelated to MU interactors.

Provision

The alternative specialisation of the contains relationship to caseswhere the containment relationship is between two behaviours ofdifferent MUs.

2.5 Implementation Details

The implementation of the internal model takes into account

specificity and efficiency

distribution

2.5.1 Specificity and Efficiency

From the FM viewpoint, behaviours have default state (normal operation)and a variety of (more interesting) degraded states. Hence normalbehaviours can be implemented as objects which are uninstantiated for agiven MU when they are functioning normally on that MU. At such times,interactors hold the inter-MU bindings and provisions between behaviours(in the model, Interactor has Binding and Provision just as MU hasBehaviour). Intra-MU support information is assumed to be class-basedand therefore has no such requirement.

The advantage of this approach is that it much reduces the number ofobjects the correlator must create as only behaviours in abnormal stateneed be instantiated.

2.5.2 Distribution

A single AC has one point of call for network information. Multiple Acsmay manage networks split geographically or organisationally. When aproblem occurs whose symptoms cross the boundary between two networkmodels, the edge MUs in each model must be able to exchange messagestransparently. This is done by splitting the interactor that relatesthem.

Hence, architecture domain bindings between MUs in the internal modelsof distinct ACs may be realised as ‘proxy’ bindings. These have the samemethods as ordinary bindings but different implementations. On receiptof a message, instead of passing it to the connected MU (not present byhypothesis), the proxy binding puts it on the output queue for that AC.It is thus sent to the input queue of the appropriate other AC whichthen sends it to the corresponding proxy binding in its internal model.FIG. 12 illustrates such distribution possibilities.

3. Correlation Strategies

The next section dicusses the reasoning ‘algorithms’ used to correlatealarms.

3.1 Generic Reasoning Aspects

The correlator's task is to build a model of the faults in the network.While doing this, it should express all and only the data needed in away that is resilient to questions of when and in what order it wasacquired.

3.1.1 Data and Knowledge

The data used in reasoning is that of the internal model, plus

a set of alarms and other events, raisable to MUs: these events maytrigger and be predicted by problems

In addition to the above instance data (data), there is class data(knowledge), and fault knowledge about

those problems (representing faults) that can occur on these MUs

support relationships between these problems and other behaviours; alsothe relations between problem and the supported behaviour states

(extra-object) service provision: what services network object classescan produce and consume, hence how these classes can be connected

the relations between problem state and event state (on the same MU forthe impact strategy, on connected MUs for the broadcast strategy)

the relations between binding state and event state

3.1.2 Data and Knowledge Acquisition

Events are sent to the correlator by the System Manager. The correlatorexpects events to arrive in a random sequence.

Ideally, the fault knowledge needed by the impact strategy will begathered by others during design and made available in a machinereadable form. Often, it will have to be gathered as part of theinstallation of a correlator on an existing type of System Manager.

Fault knowledge can be gathered

from network object class to problem class to event classes: this objectcould have this fault which would cause these events at network objectsrelated in these ways

as declarative statements:

problem=>alarms and loss of support relationships on same MU

(broadcast) problem=>alarm on connected MU

(impact) interactor degraded=>behaviour degraded and alarm on same MU

loss of support or binding relationships=>behaviour degradation

behaviour degraded=>interactor degraded and network object states

for both the impact and broadcast strategies.

3.1.3 Problem Data and Knowledge Relationships

In principle, at a given moment in its resolution, a problem could know

(from its class) the set of events, service impacts and states itpredicts will occur (in the given configuration for the broadcaststrategy; a problem class' predictions will be configuration dependent,e.g. this fault in a Sonet will cause this alarm in a connected LineCard)

(from itself) the subset of these facts that

have occurred

have timed-out or otherwise been negated

are still awaited

Hence the various set relations of non-intersection, partialintersection, equality and containment can occur between the sets ofclasses of fact that two problem classes predict and between the sets offacts that two instances of these problem classes, at a given moment,are offering to explain (the possible set relations in the latter caseare of course constrained by those in the former).

non-intersecting: the problems are resolved independently.

mutually intersecting (neither wholly contains other): neither problemcan wholly explain the observed facts so the resolution of one does notguarantee the resolution of the other.

equal: two problems are rivals to explain the same set of facts.

subset: one problem offers to explain all the facts explained byanother, plus some additional ones

When correlating using the broadcast strategy, it is simply not possibleto determine these relationships at the class level independent of theconfiguration. Because the broadcast strategy relies on problemsrecognising the relevance to them of events occurring at remotelocations connected via multiple intervening links, the number ofcombinations is just too large to enumerate. Hence,

both the generic logical behaviour required by the above intersectionrelations and the interest of specific problems in specific events underspecific conditions are encoded in the problem rules (the wise knowledgeengineer will separate these two types of rule when coding, noting thatspecific rules may occasionally wish to override the default genericbehaviour, a fact which should be documented when it occurs)

if the semantics of the situation tell the knowledge engineer that oneproblem necessarily implies the other (e.g. a catastrophic card failurenecessarily implies software error on that card), that may be capturedby a relationship between the two problem classes, governed by a genericrule.

When correlating using the impact strategy, by contrast, the fact thatall hypotheses deal solely in messages sent by neighbours overstrongly-typed MU Interactors means that one can enumerate all thepossible messages for a given hypothesis on a given MU, independent ofthe external configuration of the network. Hence,

a much higher proportion of the correlation behaviour can be encoded asdata on the hypothesis classes

related to this, there is a more constrained relationship between thelogical significance of the rule that fires when a hypothesis of a givenclass and state receives a message of a given class and state, and thelogical significance of the relationship its firing creates between thesaid hypothesis and message.

The following sections discuss the extreme cases of each strategy; inpractice, a mixture may be appropriate.

3.2 Broadcast Strategy for Alarm Correlation

The impact strategy's richer modelling of behaviours and interactors isignored below but could be used to simplify rule writing.

3.2.1 Internal Model

MUs and MU Interactors alone are used to model the network. MUInteractors are mostly bindings with but few levels of capability. Inthe application domain, a community is just a root of a capability chainand broadcasts are usually (but not necessarily) to the communitydefined by the immediately superior root.

3.2.2 Fault Model

Each MU has a single behaviour object and several problem objects. Theselatter can move from their default (absent) state to various activestates on the receipt of messages from the SM or broadcast to them fromother MUs in their community. When active, they compete for the right toexplain the alarms they have taken.

3.2.3 Event Processing

With reference to FIG. 13, an event is received by the MU managing thedevice that raised it. The MU passes it to all its problems which inturn pass it to their rules. Some rules may fire, changing the state oflocal objects, and broadcasting impact messages (usually problem statechange impacts) or the original message to other MUs.

These in turn send it to their problems and thence to other rules. Anyrule whose condition accepts the problem's state, message class andmessage state proceeds to check the relationship between the originatingand receiving MUs and the states of each, plus any relevant messagedata. If the condition is met, it fires. The firing of a rule may changethe state of that rule's arguments (MU, problem, message), create newmessages, and set up relationships between the arguments or from thearguments to other objects.

3.2.4 Rule Writing Strategy

This section briefy describes the kind of rules required by thebroadcast strategy.

3.2.4.1 Generic Rules

Class-based explanation relationship deduction is impossible. Problemimpacts are raised when problems change state. Received by otherProblems, they fire rules that check the their explanation-of-messagesrelationships and change the state of receiving and sending problemappropriately. Other generic rules handle messages sent to problems thathave been subsumed by others.

3.2.4.2 Specific Rules

Every MU has a single never-instantiating behaviour class that handlesbroadcast of events. Every problem has specific rules to decide whetherto offer to explain an event and whether to change state.

3.2.5 Class Descriptions

(Only given where they differ significantly from the impact strategybelow. See FIGS. 18-22.)

MU Interactor

(Just Interactor in figures) As we have no (behaviour) interactors, thisclass connects MUs in its own right, and not as a surrogate. By analogywith behaviour interactors, we specialise it into MU Binding and MUContainment subclasses.

Behaviour

Changes to a behaviour's logic (i.e. the rules that govern its reactionto state changes in connected objects) can only be made in when it isinactive. When it receives a message, a behaviour selects itsappropriate Logical Rule and passes the message to it.

Normal

Never leaves quiescent state.

Logical Rule

A logical rule applies to a single behaviour class-message classrelation. (It translates to a ruleset in the architecture domain.)

Rule Invocation

This class represents the occurrence of a successful rule invocation. Itstores the parameters that fired the rule and may be referenced by themessages that the rule created. This object was required by the symbolicdebugging environment for the alarm correlation engine.

Message

Messages are either events or problem state impacts.

3.3 Impact Strategy for Alarm Correlation

The impact strategy limits the messages that can be exchanged betweenMUs to ones that comment on the state of the bindings between them. Itallows the rule-writer to put more of the knowledge into datastructures, driven by generic rules. Note, however, that this is not acompulsory feature of the strategy; it could be implemented entirely asa particular style of rule-writing within an engine built to support thebroadcast strategy.

3.3.1 Internal Model

MUs have behaviours connected by behaviour interactors, as describedearlier in section 2.4.1. All have degraded states and relations betweenthese states.

3.3.2 Fault Model

Behaviour is expanded to include the concept of problem behaviours aswell as normal behaviours. Both behaviours and behaviour interactors arehypotheses; either quiescent or active (degraded). A hypothesis in agiven state may explain a message in a given state. Messages are eitherevents or impacts and in the latter case it is the object impacted thatis in fact explained, i.e. hypotheses explain events or otherhypothesis. Impact here means an information impact (eg “I have changedstate”), not a command impact (eg “change your state”). The highest endof any such explanation tree must be composed of problems (note thatproblems may be explained by other problems; they just do not requireexplanation). The lowest end must be composed of events. (Impactmessages relating to) behaviours and behaviour interactors in degradedstate make up the intervening levels.

3.3.3 Event Processing

An event change of state (i.e. from absent to present) signals thosebehaviours of its MU to which it has explain relations. These eitherdegrade and take (explain) the event or oblige an attached behaviourinteractor to degrade and explain it. Whatever hypothesis(es) offer toexplain the event, signal their state change in turn to any otherhypotheses with which they have an explain relationship, thus provokingfurther state changes.

3.3.4 Rule Writing Strategy

This section briefy describes the kind of rules required by the impactstrategy.

3.3.4.1 Generic

For given MU class, its hypothesis classes and states know what logicalrelations connect them to which message classes and states. The genericrules are those that are driven by this data to instantiate theselogical relations between actual hypotheses and actual messages when theformer receive the latter.

3.3.4.2 Specific

In an ideal world, all processing in the impact strategy would be datadriven and generic. In the real world, there will doubtless be overridesto these generic rules.

3.3.5 Class Descriptions

From the FM point of view, behaviours are only interesting when they areoperating abnormally. A behaviour is in its default (normal) state or ina degraded state. A problem is in its default (quiescent) state or in anactive state. Since the behaviour and the problem may be the same objectconsidered from different viewpoints (it's a behaviour when it's workingand a problem when it's not), the terms are used interchangeablyaccording to context. (See FIGS. 23-30.)

MU

MUs are units of granularity of management. In the FM world, they areobjects which can raise alarms and, at the physical level, can beidentified and separately replaced. An MU's state is wholly defined bythe state of the behaviours and problems of which it is composed and theMU Interactors that connect to it. It is simply a unit of granularity ofprocessing, serving to group and forward messages.

Event

Events have two basic states: default (absent) and active (raised onthis MU), just like hypotheses. However the logical state of being anexpected but not yet arrived event (analogous to state of being aprovable hypothesis) is not needed since an event is expected by aparticular problem and hence its expectation resides in the relationbetween a hypothesis state, a default event state, and a timer state ofthe explain relationship between them which was waiting for the event tobecome active. Hence events do not have the same active statesubstructure as hypotheses.

Events are not hypotheses also because they cannot explain things, beingthemselves by definition what must be explained.

MU Interactor

(Just Interactor in figures) An MU Interactor has (behaviour)interactors as an MU has behaviours. In the implementation, this classis needed to hold information about interactors in default state.

Hypothesis

A hypothesis has a default state (inactive from the point of view of FM)and various active/degraded states. A hypothesis in a given state mayexplain events or other hypotheses in given states and may be explained.The lowest level of a tree of explanations must be composed of events.The highest level must be composed of problems.

Hypotheses' active states have logical substate (true, provable, false)and user substate (unreported, reported, acknowledged, cleared). Notethat the false (and cleared) states are temporary clean-up states; afalse (or cleared) hypothesis will remove references to itself fromother hypotheses and immediately return to its default state; logicallyspeaking, default is the actual, persistent false state.

Behaviour

Every behaviour is owned by a particular MU. Behaviours know about theinternals of their MU and can map alarms to impacts.

Changes to a behaviour's logic (i.e. the rules that govern its reactionto state changes in connected objects) can only be made in when it isinactive.

When a event related to a default behaviour by an explain relationchanges from default state, (i.e. is raised), the behaviour may changestate and explain the event or it may cause one of its behaviourinteractors to change state and explain the alarm, itself remaining indefault state (for the moment; one effect of the behaviour interactor'sstate change will be a state change of the behaviour). In this lattercase, the event ‘really’ meant simply that the interactor was in adegraded state. However the interactor's attached behaviour handled itsince, by the philosophy of the impact strategy, the interactor, as ageneric extra-MU object, can only know the degradation states of itstype. It can know nothing of what an alarm on one of the many classes ofMU's to which it could be attached might mean; only the MU'sbehaviour(s) can know that.

Normal (Altenative Names: Intended, Default)

A normal behaviour in default state is operating normally. An ‘active’normal behaviour's operation is degraded in some way. In the simplestcase, the behaviour is wholly denied. A specialisation tree of behaviour(not shown on figure) contains subclasses with more elaborate statemodels catering for degrees of unavailability.

Problem

Problems explain event states and other behaviour degradation states anddo not themselves need explanation (though they may be explained byother problems). A problem in default state is not present on that MU.An active problem generates effects on those behaviours of its MU towhich it has a support (subclass of explain) relation.

Innate

Innate behaviours support others directly and internally to an MU. Theyare thus of no interest to configurers and only appear when the internalmodel is broadened to the fault model. They, and their supportrelationships, represent a kind of capability chain modelling within theMU; the breaking down of the MUs own EFSM into more fundamentalcomponents that support its externally visible behaviours when they workand degrade them when they fail.

All innate behaviours are problems (i.e. when active). An innatebehaviour's state could be explained by another's but usually there willnot be much detailed intra-MU behaviour modelling

Enhancement

Because it is an internal, non-exportable behaviour, an enhancementbehaviour is a subclass of problem as well as of normal behaviour (it'san enhancement when its working and a problem when it's not).

Capability

A capability cannot be a problem (i.e. a root of explanation) since bydefinition its states are dependent on the states of its extra-MUbindings as well as its own behaviour. Hence, even in the simplestcases, it will always be necessary to model faults as innate orenhancement behaviours supporting capabilities.

Behaviour Interactor

Behaviour Interactor degradation state changes may be the consequence ofone attached behaviour's change of state and the cause of another's.Alternatively, they may be caused by an attached behaviour'snon-state-changing reaction to an event state change.

In the context of a given MU, MU Interactor states and problem statesare rivals to explain changes to the MU's behaviours' states. That is,the interactors are the MU's interface to other MU's whose problems maybe rivals with its problems to explain its behaviours' states. In theimpact strategy, the degraded states of interactor attached to itsbehaviours are the MU's only knowledge of these other problems.

Contain

This is in principle unidirectional; the contained behaviour's degradedstate causes degradation of the containing behaviour's state.Degradation of the containing behaviour's state may be caused bydegraded state of the contained behaviour. Hence its state machine isthe same as that for interactor.

The contain relationship has no closed loops (i.e. is irreflexivelytransitively closed).

Support

A specialisation of the contains relationship to cases where problembehaviours of an MU support other behaviours of that same MU, i.e. tocases where the containment relationship is between two behaviours ofthe same MU.

Provision

A specialisation of the contains relationship to cases where thecontainment relationship is between two behaviours (necessarilycapabilities) of different MUs.

Binding

Bindings are usually bidirectional objects as they are passinginformation in two equal directions (designated portA and portZ in thefigure), although unidirectional bindings, or ones with a preferreddirection to which information in the reverse direction is subordinate,are possible. Hence, the most general binding's state is in theory thecross-product of the state of each direction's information flow.Specific binding classes will involve a greater degree of coupling.

In relation to the behaviour at a given end, one direction of flow isoutward, and thus its state will be a consequence of the behaviour'sstate, while the other is inward, and thus its state will be a cause ofthe behaviour's state.

Explain

Just as, in the application domain, the problems and alarms of which anMU is capable are regarded as always present whether in default oractive form, so the logical relationships between these, and all otherhypotheses and events, is always present. It is a relationship betweenstates of hypotheses and events. Each logical relationship knows whichstates of its explaining class are compatible with which states of itsexplained class and vice versa.

The explain relationship is idle when these states are compatible. Whenthey are not, causes will force state changes of the same logical statevalue on consequences, where these are hypotheses, and will posit anon-forcing state change (with timers whose duration is held in thelogical state) where these are events. Consequences will have a similareffect on causes, save that multiple possible causes will degrade thelogical state value of the forced change.

Evidence

This class' principal ability is to be at the explained end of anexplain relationship. Its subclasses can be represented by or impactedby messages in the architecture (and in the broadcast strategy, thoughtof as a realisation layer for the impact strategy). It knows whether itis being explained by none, one, many or too many hypotheses. Onlyproblems may end in the first state. Evidences explained by too manyhypotheses will not drive any to new states unless one hypothesis isalready in logical state true.

3.4 Implementation Details

The implementation of the internal model takes into account

specificity and efficiency

multi-AC distribution

3.4.1 Specificity and Efficiency

Every class with default and active states is implemented as an objectwhich is not instantiated on its MU when in default state (see FIG. 31).

Impact messages are simply means of sending notice of the objectimpacted to others. To save duplicating an inheritance hierarchy for allimpacts, ruleset lookup is implemented so that impacts provide theirimpacted object class to the rule dictionary, i.e. rules fired byimpacts are selected on the type of object impacted.

3.4.2 Distribution

Intra-correlator distribution is motivated by the need to handle a highvolume of incoming alarms. The correlator's manner of of processing isthat a single event sent to it by the system manager causes the firingof one or more rules, each of which may create one or more messages,which may in turn cause the firing of other rules and thus the creationof other messages. Hence, each incoming event is the route of a creationtree of messages. Thus the preferred form of internal distribution is toallocate the processing of distinct incoming events to distinctprocessors (see FIG. 32). Each event is queued and, when a processorbecomes free, it, and all messages created by it, are handled by thatprocessor. This form of distribution allows process ordering constraints(see section 1.3) to be preserved transparently to the rule writer.

Inter-correlator distribution is motivated by an organisational orgeographic need to have interconnected parts of the network managed atdistinct locations, requiring distinct, communicating correlators. Asthere is a natural quarrel between the object-oriented principle ofencapsulation and the needs of debugging, these correlators must be in apeer relationship, not a hierarchic one. Where an MU in the knowledgebase of one correlator interacts with an MU in another, the conceptualinteractor between them is impemented as two proxy interactors, one ineach knowledge base, with the same interface as a standard interactorbut different implementation (see FIG. 33). When a proxy interactor isinstructed to pass a message to its far end, it instead provides themessage to its correlators output queue, whence it is passed to theinput queue of the correlator of the other knowledge base. The othercorrelator passes the message to the far-end MU in the same manner as itwould an event sent to that MU by the system manager.

Since the transport medium between the two correlators may lose orreorder messages sent between them, the ordering constraints of section1.3 are enforced by the output queue's attaching to the exported messagea list of references to any of its antecedent creating messages thathave already been exported. The other correlator's input queue reordersthese messages, waiting for delayed earlier ones as necessary, topresent them in the order required by the constraint. The need to dothis is a performance cost but a beneficial side effect is that the samemachinery supports the detection of lost messages and the raising ofrequests for retransmission or errors. As for intra-correlatordistribution, this is transparent to the rule writer.

When both these forms of distribution are used, the demands of section1.3 mean that the proxy interactor must tag the message it exports witha reference to the intra-correlator thread of processing in which it wascreated. This thread reference must be copied to all messages created bythe exported message so that if any of them are exported back to theoriginal correlator over another (or the same) proxy interactor, theywill be processed in the same thread (if it is still running).

Lastly, when using correlation to support multiple levels of serviceimpact analysis, a hierarchically arranged system of communicatingcorrelators can be set up (in contrast to the case above). Subordinatecorrelators map alarms to problems on physical devices and send messagesabout these problems to superior correlators. These process the problemmessages as though they were alarms and, using the same methods, mapthem to higher level (network) problems. A similar process may connectnetwork to service problems and the distribution may be further refinedto cope with sublevels within these three.

By using the above approach, the correlator can secure the performancebenefits of distribution without imposing on the rule writer themaintenance burden of either adapting rules to particular distributionenvironments or abandoning natural simplifying assumptions about theorder of rule processing.

3.4.3 Logic Separation and On-line Update

The behaviour class is implemented as a static and dynamic part. Thedynamic part of a behaviour class provides a mapping between thatbehaviour class and a rule base class. This mapper object also holdsdictionaries that, both for instances of the behaviour class and for thebehaviour class itself, map between classes of message that they receiveand sets of rules that they then evaluate. The rules are implemented inrule base classes and the association between behaviour class and rulebase is achieved through the dynamic mapper object. This associationdecouples rule and behaviour knowledge completely, allowing them to haveseparate inheritance hierarchies and configuration groupings.

The mapper object's references to rule names and rule implementationsalso allows on-line updating of problem logic. By altering a staticbehaviour class' reference to point to a new dynamic mapper, which mayhave a new rulebase reference and/or new rule names in its dictionaries,the reasoning capacity of all future instances of that class can bechanged while existing instances will behave as before; this is howon-line upgrade to new rule configurations will normally be done. A lessusual procedure but one that will sometimes be advantageous whenpatching particular errors disovered in released rulebases, is to alteran existing mapper's ruleBase reference, thus changing the reasoningcapacity of existing as well as new instances.

Hence, by providing the separation of behaviour knowledge i.e. whatmessages cause what rules to be evaluated and the rules that areactually evaluated, the following is achieved:

(1) Multiple rule bases can be used within one knowledge base with eachbehaviour being assigned a single rule base.

(2) Rule bases can be exchanged at run time on a behaviour class bybehaviour class basis. In this way, the fault behaviour of existing andfuture behaviour instances can be modified.

(3) The same behaviour knowledge can be reused in the context of severaldifferent rule bases thereby reducing the duplication of rule knowledgewithin the problem. This significantly reduces the maintenance problemusually associated with a system of this type.

4. Compilation of Rules

The system extends the Smalltalk Compiler in such a way that theexisting development environment can be used unchanged for the creationof either Smalltalk methods or correlation rules. Facilities have beencreated in order to allow break and watch points to be included in thecompiled rules in order that the operational system can be debugged.This is done in a non-intrusive way; the user not having to add codemanually to the rule in order to achieve the debugging functionality.This is contrast to Smalltalk where breakpoints are inserted by addingcode statements into the code written by the user.

Rules are compiled to native Smalltalk byte codes and run at the samespeed as any other Smalltalk method. When debugging is required, specialcode statements are automatically inserted into the compiled rule thatcan be intercepted by the system debugger. Support for online rulerecompilation is provided in order to:

(1) Modify rule behaviour

(2) Switch off rule debugging.

(3) Modify the level of debugging.

4.1 What are Rules

The compiler must be extended to support rules to avoid the impedanceproblem where the user programs in one language for OO and another forrules. The extended compiler makes the embedding seamless with the userworking (apparently) unchanged in the original OO environment. Rulesconsist of three elements:

name,

conditions

actions

They compile to an AnnotatedMethod with three arguments. Optionaldebugging is supported for condition and action components. Rules cancontain ANY valid piece of Smalltalk code.

4.2 Integration with the Smalltalk System

Telling Smalltalk what compiler to use:

(class)

compilerClass

{circumflex over ( )}Loaded ifTrue: [ACRuleCompiler] ifFalse: [supercompilerClass]

(meta)

classCompilerClass

{circumflex over ( )}Loaded ifTrue: [ACRuleCompiler] ifFalse: [supercompilerclass]

This information is used when the user does an ‘accept’ within a methodbrowser pane. The compiler defined for all ‘normal’ method classes isCompiler and is defined in the class Object.

Class ACRuleCompiler inherits from Compiler. Very few methods need to berewritten:

preferredParserClass on class side to define the parser used;

translate:noPattern:ifFail:needSourceMap:handler: on instance side, totell it what to do during compilation.

Parser is implemented in ACParser, a subclass of Parser.

4.2 Standard Smalltalk Compilation Classes

The following classes make up the rest of the Smalltalk CompilationSystem. (These compiler classes are not particularly well implemented inSmalltalk, having long methods, use of instvars instead of accessors andother signs of hacking.)

ProgramNode (and subclasses represents parse nodes in the parse treegenerated for the method. The emitXXX: aCodeStream messages actuallygenerate the compiled code (e.g. VariableNode represents an argument,temporary, instance etc. variable.)

CodeStream accumulates code for the compiler (analogous to a characterstream but composed of program nodes).

Scanner tokenizes the method source.

MethodNodeHolder encapsulates MethodNode instances (present for backwardcompatibility).

CompilerErrorHandler (subclasses deals gracefully with compilationerrors.

ProgramNodeBuilder is a class that knows how to create ProgramNodeobjects. This had to be subclassed just because of a hardcoded class inone method, a (minor) deficiency in the bject-orientedness of theoriginal Smalltalk compiler implementation.

NameScope (subclasses) represents a scope i.e. local, global, argument.

VariableDefinition (subclasses) represents the definition of a variable.There are five kinds of variable: argument, temporary, instance, static(class/pool/global), receiver (self), and pseudo (thisContext). Namedconstants (nil/true/false) are not variables. ‘super’ is not a variable,but it behaves like one in some respects.

ReadBeforeWrittenTester

4.3 Extended Rule Compilation Framework Classes ACProgramNodeBuilder, asubclass of ProgramNodeBuilder, overrides the method newMethodSelector:primitive:errorCode:block:attributes: in order that an ACRuleNode isgenerated by the compilation process instead of a method node. (If thecode in these methods were better written, it would be possible to avoidoverwriting these methods.)

ACRuleMethod, a subclass of AnnotatedMethod (which is normally used forprimitives such as Canvas), is the output of the compilation process. Itavoids the need to maintain separate source and compiled rulebases. Itdefines printOn: method only.

ACRuleNode, a subclass of MethodNode, is the root node in the parse treegenerated during the compilation of a rule. It stores the name of therule (formerly used to reference the source but now unnecessary due tothe use of annotated methods).

The ACParser Class generates the parse tree for the rule. It is createdby the actions of the ACRuleCompiler. Conditionally, it can:

insert debugging code to catch condition evaluation;

insert debugging code to catch each action evaluation.

It overrides the methods:

method:context: (illustrated in appendix)

readStandardPragmas:temps: (illustrated in appendix)

statementsArgs:temps: (illustrated in appendix) (this is only overriddento manage highlighting of nodes in the rulebase debugger)

These in turn call other methods that require alteration:

readConditions:temp:: (illustrated in appendix)

condition:temps (illustrated in appendix)

readActions (illustrated in appendix)

statementsArgs:temps: (illustrated in appendix)

4.4 Modifying the Code Stream

The code stream is modified whenever debugging or tracing is on. Thestandard sequence:

acme: arg1 problem: arg2 msg: arg3 <name> ‘a name’ <condition> arg1test. <actions> arg2 action1. arg2 action2. is instead complied to:acme: arg1 problem: arg2 msg: arg3 self changed: #conditions. arg1 testif True: [ self changed: #actions. arg2 action1. self changed: #actions.arg2 action2.

which allows tracing and stepping through rule execution in the debuggervia the standard smalltalk Model-View-Controller dependency mechanisms.

4.5 Summary

A rule compiler embedded in Smalltalk has been constructed. ExistingSmalltalk code can be used without restriction in both condition andaction parts of a rule. Existing smalltalk development tools can be usedfor rule development and testing. An advanced rule debugger has alsobeen built.

5. Summary of Advantages

The approach to network modelling described above supports local andsemi-local reasoning, in contrast to conventional network alarmcorrelation systems, whose rules (must) range over the whole network,greatly increasing the difficulty of writing and maintaining them. Also,there is a complete separation of fault knowledge from the specifictopology of a network, thereby allowing a single knowledge base tosupport all Nortel customer network configurations.

5.1 Advantages of Managed Units to encapsulate Behaviour

The AC engine inferences over Managed Units (MUs) that are in (oftenone-to-one but sometimes complex) correspondence with managed objects inthe system manager's information base. The managed unit provides thecomputational object for alarm correlation (or, more generally, faultmanagement), while the managed object provides the data object. (Thisseparation is in accord with Telecommunications Management of Networks(TMN) standards.) MUs encapsulate all aspects of the standard Fault,Configuration, Accounting, Provisioning and Security (FCAPS) behaviourfound in a network management system. Specifically, MU classes areassociated with several problem classes i.e. only faults of particulartypes can occur on given MU classes.

In contrast to managed objects, which merely record their existing stateand whether they are connected to others, MUs know the services they arereceiving, those they are offering, the states of each (functioningnormally, degraded to degree . . . ) and the rules that relate thestates of the first to those of the second.

This gives the following advantages of encapsulation as these apply tothe network management area.

Support for local reasoning: knowledge engineers can develop alarmcorrelation rules to model the fault behaviour of an MU without needingto understand the objects it connects to in detail.

Support across the life cycle: telecomms designers using the MU conceptcan specify accurate fault behaviour at an early stage of designing adevice.

Support across network management functions: the knowledge thus migratedfrom the rules of a conventional alarm correlator into the network modelis precisely that which other network management functions may wantand/or may be able to supply.

Support across diverse networks: the mapping of diverse managed objectconcepts into a single Managed Unit concept allows the correlator tomodel, and so correlate alarms from, heterogeneous networks.

It also means that the alarm correlation engine is at the same time anengine which can deduce the consequences of faults on higher levelfunctions of the network, including those visible to the user. Whichfunction it exhibits depends on what rules are supplied to it.

5.2 Advantages of Correlation Communities

The service offer and receipt links of Managed Units define chains ofinterdependent Managed Units (A supports B which supports C . . . ). Aknowledge engineer can identify selected roots of these chains asCorrelation Communities, within which a burst of alarms is likely torelate to a single fault on a single member Managed Unit.

Where full scale modelling of Managed Units is impractical (e.g. certainlegacy systems), or to provide initial alarm correlation functionalitybefore detailed modelling of the Managed Units is complete, thesecommunities can be identified early to support semi-local reasoning.

5.3 Advantages of Knowledge Structure

The Alarm Correlation Engine is a hybrid rule and message passingsystem. Problem objects communicate with each other via messages.Problem objects process the messages they receive using rules. Rules aregrouped into categories that process specific classes of message. Groupsof rules are defined for both problem classes and problem instances.This structuring of knowledge ensures fast alarm correlation with feweror simpler rules and fewer messages being passed.

5.3.1 Advantages of Faults as Problems

In contrast to conventional Intelligent Alarm Filtering (IAF) systems,which seek to identify ‘important’ alarms and filter them from thebackground noise, the AC engine uses a problem-based approach, with aproblem mapping to a fault on a device. As the MU is the AC engine'smodel of the real-world device, so the problem object is the AC engine'smodel of the real-world fault. This gives:

independence of telecomms designer's assumptions about what alarms toraise; these can often be inadequate with regard to the needs of alarmcorrelation;

ability to combine pure alarm correlation with testing and state checksand corrective actions; as well as intercepting alarms the problem canlaunch tests, verify complex conditions and control recovery behaviour.The combining of rules to do these tasks with pure correlating of thestream of alarms would be harder without the problem construct; and

an MU class can (potentially) have many types of fault, each onedescribed as a single Problem class, thereby providing clear separationof MU and Problem modelling. This enables Problem class reuse acrossmany MU classes.

5.3.2 Advantages of Message-based Reasoning

In contrast to conventional Intelligent Alarm Filtering (IAF) systems,which use standard knowledge-based communication between rules in alarge rulebase applying to many possible faults, the AC engine's unitsof reasoning (Problems) communicate via object-oriented messages andprocess the messages that they receive using rules. Messages may relateto alarms received by the AC engine or to state changes within the MUs.Problems may also be contained in messages thereby allowing for directreasoning about faults occurring in the network.

This gives the ability to distribute alarm correlation processing overseveral processors; messages can be sent between AC engines running ondifferent processors and multiple threads of reasoning, each handling adifferent incoming alarm, can run on multiple processors within a singleAC engine.

Consequently, this solution can easily be scaled up to handle a widerange of network sizes and topologies and real-time requirements.

5.3.3 Advantages of Problem and RuleBase Association

Problems process the messages that they receive using rules. Problemsdefine the association between received messages and the rules that areto be evaluated for such events. This has the advantage of ensuring thatrules are not evaluated unnecessarily, thereby improving real-timeperformance. Rules are not directly encoded within problems but aregrouped together in RuleBase classes. This separation of problemknowledge and rule implementation allows for maximal rule reuse, therebysimplifying the knowledge maintenance process.

5.3.4 Advantages of Rule Structure

Rules are implemented as the behaviour of RuleBases; one rulerepresented by a single method within the class. The AC engine's designof integrating knowledge-based techniques with object-orientedtechniques has several unique features.

The use of object-orientation to provide:

strongly hierarchical knowledge structuring mechanisms for rules;

the ability to fire rules on classes or instances of objects; and

rule reuse between product knowledge bases and within the elements of asingle product knowledge base.

This means that RuleBase classes form a hierarchy such that rules in onerulebase are effectively available to, but can have their behaviourmodified in, a rulebase lower in the hierarchy.

This gives the supplier the ability to write technology-specificrulebases and then and product-specific rulebases for particularimplementations of the technology. Little rule overriding is needed forthe technology rules to give valid alarm correlation behaviour for theparticular implementation and, more importantly, inheritance keeps thetechnology and product rulebase' rules separate, thus solving what wouldotherwise be a complicated configuration management problem.

This is even more valuable when customers wish to write their own rules.It makes customer maintenance of rulebases feasible; customers canmodify their own rulebases, while the generic supplier-providedrulebases are updated by software release. The customer's rules residein their rulebase which inherits from the product rulebase. New productrulebase versions can be released without overwriting the customer'srules and without needing to find their rewrites of the earlier versionand export them to the new version, as in a conventional alarm filteringsystem.

5.4 Advantages of Rule Encoding

The encoding of rules directly in the OO language of implementationavoids the “impedance mismatch” problem. (Impedance mismatch is aclassical problem arising from the clash between the data modellingstyles of two paradigms, in this case 00 and KBS. This clash imposes ahigh cost of translation, both in performance when running the system,and in code maintenance when coding the translation between modellingstyles.) The distinctive features of this approach include thefollowing:

rules have names for user reference, and meaningful explanation of thereasoning process;

rules are implemented by overloading the existing smalltalk compiler,not as a distinct, coupled system, thereby allowing all smalltalk codingand testing tools to be used directly on rules;

The complete power and wealth of the Smalltalk class library and ofNortel Smalltalk applications is thus available not merely within therules but also when writing, compiling and testing them.

5.5 Advantages of Dynamic Representation of the Problem Class

The use of a dynamic representation of the problem class (the rulebehaviour of problems is held, not in the problem class as inconventional Smalltalk systems, but in a dynamic object associated withit) makes the relationships of rules and problems the subject ofrun-time data.

Thus a new rulebase can be supplied to a running system and assigned tonew dynamic representations of given problems. Any existing activeproblems will continue to behave according to the logic of the old rulesuntil they expire but new problems will have the new behaviour. Bycontrast, a conventional system would require the alarm correlationfunction to be discontinued while its rulebase was changed and existingproblems would have to be lost and recorrelated from the alarm streamlog.

6 Concluding Remarks

Although the embodiments of the invention described above relate toalarm correlation, other applications and variations of the techniquesare envisaged within the scope of the claims Other variations will beapparent to a skilled man within the scope of the claims. A 12 pageAppendix of code illustrating the compiler extension aspect now follows.

translate: translate: aStream noPattern: noPattern ifFail: failBlockneedSourceMap: mapFlag handler: handler “noPattern is true forevaluation, false for compilation Make special provisions for compilingmethods in classes that still use the old parser.” | holder codeStreammethod ruleNode ruleParser myMapFlag srcInfo | myMapFlag := mapFlag or:[tracing or: [debugging]]. “for saving sourse” ruleParser := (classparserClass new) tracing: tracing; debugging: debugging; yourself.“create ACRuleParser” ruleNode := ruleParser “returns ACRuleNode root ofrule's parse tree” “creates” parse: aStream “parse” class: class “treeby” noPattern: noPattern “invoking” context: context “scanner”notifying: handler “on char” builder: ACProgramNodeBuilder new “stream,”saveComments: myMapFlag “parsing” ifFail: [{circumflex over( )}failBlock value]. handler selector: ruleNode selector.“save selectoris case of error” codeStream := self newCodeStream. “generate codestream” codeStream :=clasee restartSignal handle: [:ex]| codeStream :=self mewCodeStream. ex restart] do: [codeStream class: tragetClassouterScope: self scopeForClass; requestor: handler myMapFlag ifTrue:[codeStream saveSourceMap]. noPattern ifTrue: [ruleNode emitValue:codeStream inContext: context] ifFalse: [ruleNode emitEffect:codeStream]. “noPattern is true for ‘do it’, false when compiling (wealmost always are compiling => emitEffect is what matters to us). Thusoutputs actual generated byte codes.” method := codeStream makeMethod:ruleNode[. make compiled method method := ACRuleMethod fromMethod:method. convert to annotated method “Create a compilied rule. Save nameand compiler flags. method attributes: IdentifyDictionary new. ruleNodeattributes ==nil ifFalse: [method attributes: ruleNode attributes].(method attributes) at: #name put: ruleNode name; at: #tracing; at:#debugging put: debugging. holder := self newMethodHolder. holder node:ruleNode. holder method: method. “Save” myMapFlag “source” ifTrue: “infoand” [srcInfo := srcInfo]. “return” method attributes at: #sourceInfoput: srcInfo. holder sourceInfo: srcInfo]. {circumflex over ( )}holder”Returned object is used to out compilied rule into class dictionary,(just as if it were a smalltlak method).” “Various error handlers can bechosen, e.g. one for filing in (silientish), a noisier one for accept.”

method:context: method: fromDoIt context: ctxt “pattern [ | temporaries] name string conditions block actions block => ACRuleNode. this isinvoked inside the ‘create” parse tree’commented part of “translate . .. ’” | start pat messageComment ruleNode tempNodes | start := fromDoItpat :=fromDoIt ifTrue: [ctxt == nil ifTrue: [Array with: #DoIt with: #()] ifFalse: [Array with: #DoItIn: with: (Array with: (buildernewParameterVariableL (builder newVariableName: ‘DOITCONTEXT’)))]]ifFalse: [self patttern]. “parse the selector and assign it to a localvariable ‘pattern’. ‘pattern’ is actually an arrray of two objects(compiler is hacked).” (pat at: 2) size == 3 ifFalse: [“pat={selector,arguments}”  {circumflex over ( )}self expected; ‘3 arguments (acme,problem, message)’]. “rule arity” messageComment :=currentComment.currentComment := nil. “Begin to create new rule by creating top levelparse tree node.” ruleNode := builder newMethodSelector: (pat at: 1).tempNodes := tokenType == #verticalBar ifTrue: [“parse temporariesbefore primitive, to allow for old language.” self temporaries] ifFalse:[newLanguage ifTrue: [nil] ifFalse: [#( )]]. fromDoIt ifFalse: [selfreadStandarPragmas: ruleNode temps: tempNodes] ifTrue: [self nameFor:ruleNode startingAt: 1]. “the above parses the rule nae (accepting =>false, doIt => true).” Now we parse the rule conditions and actions(note that readConditions parses both the conditions and the actions).”self readConditions: (pat at: 2)temp: tempModes. tokenType == #doItifFalse: [{circumflex over ( )}self expected: ‘Nothing more’]. “becausewe accepted instead of doIt => parsing is all.” ruleNode block:parseNode. ruleNode addComment: messageComment. ruleNode sourcePosition:(start to: self endOfLastToken). {circumflex over ( )}ruleNode

readStandardPragmas:temps: Compiles the name of the rule. Looks for<name>0 and saves the string following (type enforced).readStandardPragmas: methodNode temps: temps “Ensure that we can parseStandard Smalltalk plus the named rule” ((self matchToken: #<) and:[(self matchToken: ‘name’) and: [self matchToken: #>]]) ifTrue: [selfnameFor: methodNode] ifFalse: [super readStandardPragmas: methodNodetemps:    temps]

readConditions:temp: Comples the condition and actions parts of rule.Lokks for <conditions> and then parses a sequence of smalltalkstatements. readConditions: argNodes temp: tempNodes “Parse theconditions part of the rule” {circumflex over ( )}((self matchToken: #<)and: [(self matchTokenL ‘conditions’) and: [seld matchToken: #>]])ifTure: [self conditionArgs: argNodes temps: tempNodes. parseNode]ifFasle: [self expected: ‘<conditions>’

condition:temps: condition: argNodes temps: tempNodes “Parse a conditionconsisting if a series of expression statements” | start blockCommentconditionalNode stmts | blockComment := currentComment. “save commentslest we reformat” currentComment := nil. start := endTemps. selfexpression ifTrue: [(self match: #period) ifFalse: [{circumflex over ()}self expected: ‘period’]. conditionsNode isNil ifTure: [conditionsNode:= start]. ifFalse: [{circumflex over ( )}self expected: ‘period’].conditionsNode isNil ifTrue: [conditionsNode := start]. conditionalNode:= ConditionalNode new condition: parseNode trueBlock: (self conditionLargNodes temps: OrderedCollection new) falseBlock: self emptyBlock from:nil] ifFalse: [debugConditionsNode := self endOfLastToken. {circumflexover ( )}self readActions: argNodes temp: tempNodes]. self addComment.stmts := self isTracing ifTrue: [self tracing: false. OrderedCollectionwith: (self insertConditionDebugCode sourcePosition: (conditionsNode to:debugConditionsNode))] ifFalse: [OrderedCollection new]. stmts addLast:conditionalNode. parseNode := builder newSequenceTemporaries: tempNodesstatements: stmts. parseNode addComment: blockComment. parseNodesourcePositions: (start to: self endOfLastToken + (tokenType =#rightBracket ifTrue: [0] ifFalse: [1])). {circumflex over ( )}parseNode:= builder newBlockArguments: argNodes body: parseNode

readActions Compiles the actiona part of the rule readActions: argNodestemp: tempNodes “parse the actions part of the rule” {circumflex over ()}((self matchToken: #<) and: [(self matchToken: ‘actions’) and: [selfmatchToken: #>]]) ifTrue: [self statementsArgs: argNodes temps:tempNodes. parseNode] ifFalse: [self expected: ‘<actions>’]

statementsArgs:temps: statementsArgs: argNodes temps: oldTemps “oldTempsis nil if temps should be parsed. This is for compatability with the oldlanguage, so that temps can be parsed before the promotivespecification.” | tempNodes stmts start blockComment returnStartstmtNode | oldTemps ==nil ifTrue: [tempNodes := self temporaries]ifFalse: [tempNodes :=oldTemps]. stmts := OrderedCollection new. “giveinitial comment to block, since others trail statements” blockComment :=currentComment. currentComment := nil. start := endTemps. [tokenType ==#upArrow ifTrue: [returnStart := mark. self scanToken. self expressionifFalse: [{circumflex over ( )}self expected: ‘Expression to return’].self isDebugging ifTrue ]stmts addLast: self insertActionDebugCode].parseNode := uilder newReturnValue: parseNode. self addComment.parseNode sourcePositionsL (returnStart to: seld endOfLastToken). stmtsaddLast: parseNode. self match: #period.“allow optional trailing . after{circumflex over ( )}” false] ifFalse: [self expression ifTrue: [selfaddComment. stmtNode := parseNode. (self isDebugging and: [parseNodehasEffect]) ifTrue: [stmts addLastL self insertActionDebugCode]. stmtsaddLast: stmtNode. self matchL #period] ifFalse: [false]]] whileTrue.self addComment. stmts isEmpty ifTrue: [Dialog warn: ‘No rule actions isdefined’. returnStart := mark. parseNode := builder newReturnValue: selfclass selfVariableNode. self addComment. parseNode sourcePosition:(returnStart to: self endOfLastToken). stmts addLastL parseNode]. (stmtssize = 1 and: [blockComment == nil and: [parseNode := stmts first.parseNode sourcePosition == nil and: [tempNodes isEmpty]]]) ifTrue: [“Nopoint in building a sequence”] ifFalse: [parseNode := buildernewSequenceTemporariesL tempodes statements:stmts. parseNode addComment:blockComment]. parseNode sourcePosition: (start to: selfendOfLastToken + (tokenType = #rightBracket ifTrue: [0] ifFalse: [1])).parseNode := builder newBlockArguments: argNodes body: parseNode

What is claimed is:
 1. An automated method of processing data from acommunications network comprising a plurality of network entities,having predetermined states of operation, the method comprising thesteps of: creating a plurality of different objects each associated withdifferent possible rival states of one of the entities, the objectscomprising knowledge based reasoning capability for determining whetherthe entity is in a given one of the possible rival states; passing dataabout the network to the objects; and inferring whether the entity is inthe given one of the possible rival states using the reasoningcapability.
 2. The method of claim 1 wherein the given state is a faultstate.
 3. The method of claim 2 wherein the data about the networkcomprises alarms and other events relating to abnormal or undesiredoperation of the network.
 4. The method of claim 3 wherein the methodfurther comprising the step of passing messages between the objects aspart of the inference process.
 5. The method of claim 1 wherein theobject creation step is triggered by an event notified by the network,and the given state is a possible cause of the event.
 6. The method ofclaim 1 wherein the object creation step is triggered by an eventnotified by the network, and the given state is a possible consequenceof the event.
 7. The method of claim 1 wherein the reasoning capabilitycomprises rules grouped according to the class of messages they canprocess.
 8. The method of claim 1 wherein the reasoning capabilitycomprises rules for translating events notified by the network into adegradation of a service received or offered by the associated entityfrom or to other entities.
 9. The method of claim 8, further comprisingthe step of passing such service degradation information to otherobjects associated with the same or the other entities.
 10. The methodof claim 1, wherein the inference steps for each object are carried outin parallel in threads sharing a common knowledge base.
 11. The methodof claim 1 wherein knowledge bases are built up for each part, themethod of claim 1 is carried out in parallel on the separate parts, andthe inference step is carried out using respective ones of the knowledgebases, and messages from one object in one knowledge base to a connectedobject in another, are passed transparently.
 12. The method of claim 11wherein a plurality of said objects are created, in one of the knowledgebases, and the inference steps for each of these objects are carried outin parallel, in threads wherein messages passed from these objectscontain a reference to the thread in which they were processed.
 13. Amethod of acquiring knowledge for the knowledge based reasoning capacityfor the method of claim 1, comprising the step of creating rules fortranslating events notified by the network relating to the associatedentity, into a degradation of a service offered by the associated entityto other entities.
 14. An automated method of processing data from acommunications network, comprising the step of: applying a knowledgebased reasoning capability to interpret the data, wherein the reasoningcapability comprises object orientated hierarchy of rule bases, thehierarchy being arranged to have object orientated inheritanceproperties, such that the method further comprises the steps of:determining whether a named rule is in one of the rule bases, and whereit is not present, making available the same named rule from a rule basehigher in the hierarchy; and applying the named rule to the data. 15.The method of claim 14 wherein the data comprises events notified by thenetwork, and the named rule is for inferring the cause of one of theevents.
 16. An automated method of processing data from a communicationsnetwork comprising the steps of: providing a knowledge based reasoningcapability wherein the reasoning capability comprises one or morerulebases, comprising rules encoded directly in an object orientedlanguage; providing an object oriented compiler; and applying saidknowledge based reasoning capability to interpret the data byspecialising selected classes of the compiler so extending itsfunctionality that it compiles rules and standard code.
 17. The methodof claim 16 wherein the rules comprise rules for processing eventsnotified by the network, the method comprising the step of applying thereasoning to determine the cause of the events.
 18. The method of claim16 wherein the compiler is a smalltalk compiler.